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Quarterly  Technical  Report  #2 
EUCLID  Compiler  Project 
Report  Summary 

This  second  quarterly  technical  report  covers  the  period  from 
1 April  1978  to  30  June  1978.  During  that  time  three  major 
steps  were  taken: 

(a)  the  general  designs  developed  earlier  became  much 
more  detailed  providing  specifications  for  the 
individual  passes  of  the  compiler. 

(b)  implementation  (coding)  of  the  four  remaining 
passes  began  and  is  well  under  way. 

(c)  communications  with  the  principal  users  of  the 
compiler  (the  KSOS  team  at  Ford  Aerospace)  were 
firmly  established  so  that  their  needs,  in  terms 
of  both  technical  requirements  and  schedule, 
could  be  understood  and  met  by  the  implementation 
team  at  the  University  of  Toronto. 

As  a result  of  this  communication  the  product  known  as  Middle 
EUCLID  which  was  to  have  been  delivered  at  the  end  of  July  has 
been  postponed.  Instead,  Ford  Aerospace  agreed  to  the 
delivery  of  an  "October  EUCLID"  in  October  embodying  their 
requirements.  In  the  interim,  as  pieces  of  the  compiler  are 
fitted  together  to  provide  stand  alone  iterations  towards 
October  EUCLID,  these  will  be  delivered  informally  to  Ford. 
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Quarterly  Technical  Report  #2 
EUCLID  Compiler  Project 


I.  BACKGROUND 

The  work  described  herein  is  part  of  the  effort  to  achieve  a 
compiler  for  the  language  EUCLID  for  the  PDP-11.  This  work  is 
part  of  the  major  project  to  achieve  a secure  operating  system. 
Ford  Aerospace  has  been  given  the  contract  to  develop  such  an 
operating  system  for  the  PDP-11  to  be  known  as  KSOS 
(Kernalized  Secure  Operating  System)  and  they  are  seen  as  the 
principal  users  of  the  EUCLID  compiler. 

A portion  of  the  EUCLID  project  is  being  funded  by  the  Canadian 
Department  of  National  Defence  (DND)  . The  project-team  is 
located  in  Canada:  the  work  is  essentially  being  done  at  the 
University  of  Toronto  by  people  in  the  Computer  Systems 
Research  Group  in  conjunction  with  I.P.  Sharp  Associates  Limited. 
The  monitoring  is  being  done  jointly  by  DND  and  by  ARPA. 


II.  THE  APPROACH 

The  work  of  the  past  three  months  may  be  divided  into  a number 
of  separate  sections.  These  are: 

(i)  Design; 

(ii)  Implementation; 

(iii)  Communications  with  Ford; 
and  (iv)  Communications  with  the  EUCLID  Committee. 

We  shall  consider  each  of  these  separately  and  in  turn. 


4 


(i)  Design 


From  the  general  design  of  the  compiler  which  has 
evolved  and  is  to  be  found  piecemeal  in  the  working  papers  (See 
Appendix  B) , a more  detailed  set  of  specifications  has  been 
developed.  These  specifications  are  for  the  four  passes  of  the 
compiler  (known  as  the  Builder,  the  Conformance  Pass,  the 
Allocator,  and  the  Coder)  which  follow  the  two  already  well 
established  (the  Scanner  and  the  Parser) . 

The  Builder  is  concerned  with  creating  the  symbol  table 
and  type  tables,  find  appropriately  modifying  the  token  stream 
which  flows  successively  through  the  remaining  passes  until  the 
Coder  provides  object  code. 

The  Conformance  Pass  determines  the  semantic  legitimacy 
of  the  source  code  and  uses  the  type-sameness  rule  mentioned  so 
often  in  the  message  file  (Appendix  C) . This  pass  together  with 
the  Builder  constitutes  the  semantic  portion  of  the  compiler. 

The  Emitter  passes  - the  Allocator  and  the  Coder  - are 
the  machine  dependent  portion  of  the  compiler.  Up  to  this 
point,  although  some  reference  must  be  made  to  the  host  machine, 
the  compiler  is  largely  machine  independent. 

(ii)  Implementation 

The  actual  implementation  of  these  four  remaining  passes 
is  well  under  way.  It  is  when  these  passes  have  been  coded  and 
integrated  with  one  another  that  serious  testing  and  enhance- 
ment may  take  place.  It  is  the  general  philosophy  that  an 
initial  version  will  be  put  together  which  omits  many  of  the 
features  ultimately  to  be  supported.  Once  this  version  is  shown 
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to  work  satisfactorily,  the  features  will  be  incrementally 
incorporated  until  the  final  version  is  finished.  The  first 
stand  alone  version  is  expected  at  the  end  of  July  or  early  in 
August,  but  may  be  later. 

(iii)  Communications  with  Ford 

As  the  result  of  establishing  a dialogue  with  the 
principal  user  of  the  compiler  (the  Ford  Aerospace  team  writing 
KSOS)  two  significant  items  need  reporting. 

(a)  The  needs  of  the  Ford  team  are  much  better  under- 
stood now  by  the  implementation  team.  As  a result 
the  order  of  the  increments  to  the  compiler  has 
been  slightly  altered  to  conform  to  the  expressed 
requirement  of  the  team.  Moreover,  the  version 
known  as  Middle  EUCLID  has  been  postponed  and 
redefined  as  October  EUCLID.  This  will  now  be 
delivered  to  Ford  at  the  beginning  of  October  (or 
before)  and  will  contain  an  agreed  minimal  set  of 
features.  (Appendix  C defines  Middle  EUCLID, 
while  Appendix  D defines  the  revised  version.) 

(b)  The  experience  of  the  Toronto  team  in  writing 
EUCLID  code  and  in  writing  the  compiler  will  be 
transferred  to  Ford  by  means  of  a tutorial  to  be 
held  in  early  August  at  Palo  Alto.  This  is  to 
improve  the  Toronto  team's  sensitivity  to  the 
needs  of  the  KSOS  team,  as  well  as  to  provide  the 
KSOS  team  with  the  benefit  of  Toronto's  acquired 
knowledge  of  the  peculiarities  of  EUCLID. 
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(iv)  Communication  with  the  EUCLID  Committee 

Because  the  language  is  now  much  more  stable,  the  level 
of  communications  between  the  committee  and  the  Toronto  team  has 
diminished.  Appendix  E lists  the  ARPANET  messages  since  the 
beginning  of  1978.  Although  there  has  been  a flurry  recently, 
this  has  centered  principally  on  the  revised  report  which  the 
committee  has  issued.  It  is  expected  that  this  revised  report 
will  be  available  to  those  requiring  it  from  I.P.  Sharp  Associates. 
It  will  be  made  publically  available  when  this  draft  revision 
has  been  generally  corrected  and  accepted. 

III.  WORKING  PAPERS 


The  current  index  of  working  papers  is  shown  as  Appendix  B. 


APPENDIX  A 


Progress  Report  No  2 
(1  April  - 30  June  1978) 


During  the  period  April  1,  1978  to  June  30,  1978  the  EUCLID 
implementation  project  was  primarily  concerned  with  developing 
detailed  designs  from  previous  general  designs,  and  with  the 
beginning  of  implementation  of  semantic  passes.  During  this 
period,  communication  with  the  secure  operating  system  project 
at  Ford  Aerospace  produced  a detailed  list  of  their  require- 
ments for  the  EUCLID  translator. 


The  next  major  goal  is  the  production  of  a EUCLID  translator 
that  produces  PDP-11  code,  and  which  can  translate  (bootstrap) 
itself.  The  translator  will  consist  of  six  major  passes:  the 
Scanner  and  Parser  (already  constructed  and  tested) , two 
semantic  passes  (the  Builder  and  Conformance) , and  two  emitter 
passes  (the  Allocator  and  Coder) . 


The  progress  during  this  period  included: 


Detailed  design  of  the  Builder  pass  produced  revised 
specification  of  the  disk-resident  symbol  and  type 
tables,  as  well  as  detailed  documentation  of  the 
Builder-produced  token  stream. 

Detailed  design  of  the  Conformance  semantic  pass 
produced  specification  of  tests  (e.g.,  arithmetic  type 
checking)  to  be  performed  by  the  pass. 

The  Builder  and  Conformance  passes  entered  initial 
stages  of  implementation. 

Detailed  design  of  emitter  mechanisms  produced:  set 
operation  code  templates,  routine  call/return  code 
templates,  preliminary  register  allocation.  Boolean 
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operation  code  templates,  scheme  for  addressing 
modules  and  extended  parameters,  and  scheme  for 
compile-time  representation  of  variable/constant 
values. 


R.C.  Holt 
CSRG 

13  July  1978 

f 
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APPENDIX  C 


Middle  EUCLID 

(Working  Paper  54) 

The  continuing  evolution  of  the  EUCLID  language  has  caused 
some  delay  in  the  original  EUCLID  implementation  schedule. 

This  working  paper  attempts  to  document  the  EUCLID  language 
features  that  will  not  be  supported  by  the  prototype  translator 
that  will  be  delivered. 

A language  feature  that  is  DEFERRED  will  definitely  not  be 
supported  by  the  prototype  translator.  Language  features  that 
MAY  BE  DEFERRED  will  be  supported  by  the  prototype  translator 
if  the  Implementation  Team  has  sufficient  time  to  implement 
them. 

A meeting  in  January  1978  between  the  EUCLID  committee  and  the 
EUCLID  implementation  team  resulted  in  some  substantial  changes 
to  the  language.  The  prototype  translator  will  implement  the 
language  as  revised  by  this  meeting.  The  EUCLID  Committee 
under-took  to  produce  a revised  report  on  the  EUCLID  language 
by  mid  March  1978.  It  is  now  expected  that  this  revised  report 
will  be  available  in  late  June  1978. 

The  EUCLID  subset  supported  by  the  prototype  translator  will  be 
somewhat  larger  than  Small  EUCLID  and  will  be  tailored  to  the 
needs  of  the  Implementation  Team  and  the  EUCLID  Users.  The 
subset  contains  all  the  features  of  Small  EUCLID,  and  is  called 
Middle  EUCLID. 
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The  remainder  of  this  paper  lists  the  deferred  and  possibly 
deferred  language  features  and  also  notes  major  changes  that 
are  a result  of  the  January  1978  meeting.  For  ease  of 
reference,  the  section  numbers  and  headings  of  the  February  1977 
EUCLID  report  have  been  used. 


3.2  Legality  Assertions 

Legality  assertion  generation  is  DEFERRED. 

5.  Manifest  constants 

The  formal  parameters  of  a type,  when  used  in  the  body 
of  the  type,  are  never  considered  to  be  manifest  even 
if  the  corresponding  actual  parameters  for  an  instance 
of  the  type  are  manifest  constants  (JAN  1978) . 

6.1.1  Enumerated  types 

The  functions  T.Min  and  T.Max  will  be  restricted  to 
exactly  two  arguments.  The  Min  and  Max  functions  MAY 
BE  DEFERRED. 


6.1.2  Standard  simple  types 

The  concept  of  well-behaved  and  the  arithmetic 
operations  for  unsigned  integers  have  been  revised  and 
restricted  (JAN  1978)  . 

The  spelling  of  standard  type  names  has  been  revised 
so  that  all  standard  type  names  now  begin  with  a 
capital  letter  (JAN  1978) . 

6.1.3  Subrange  types 

If  an  integer  subrange  type  has  non-manifest  bounds 
then  it  must  be  contained  in  Signedlnt  when  the  bounds 
are  evaluated. 

6.2.1  Array  types 

The  implementation  of  arrays  with  non-manifest  bounds 
MAY  BE  DEFERRED. 

If  the  componentType  of  an  array  is  a subrange  type 
then  that  subrange  type  must  have  manifest  bounds 
(JAN  1978). 
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6.2.2  Record  types  and  String  Type 

Subrange  types  used  to  declare  variables  and  constants 
in  a record  definition  must  have  manifest  bounds 
(JAN  1978)  . 

Arrays  with  non-manifest  bounds  inside  records  MAY  BE 
DEFERRED. 

Direct  nesting  of  variants  (i.e.  case  within  a case)  is 
DEFERRED.  The  same  effect  may  be  achieved  by  wrapping 
a record  declaration  around  the  inner  case. 

The  itsTag  standard  component  has  been  added  to  allow 
reference  to  the  value  of  a variant  records  tag 
(JAN  1978) . 

The  tag  of  a variant  record  definition  must  be  exactly 
an  identifier  corresponding  to  a formal  parameter  of 
the  record  type.  Manifest  constant  expressions  used  in 
the  tag  field  are  DEFERRED. 

Labels  in  variant  record  cases  are  restricted  to  being 
literal  constants,  named  literal  constants,  or  sub- 
ranges thereof.  Manifest  constant  expressions  used  as 
variant  case  labels  are  DEFERRED. 

The  standard  type  String  is  supported  and  is  changed  to 
be  simply  a packed  array  of  characters  with  the  upper 
bound  of  array  being  a parameter  to  the  type  (JAN  19  78)  . 

6.2.3  Module  types 

Validation  of  import  and  export  restrictions  will  be 
DEFERRED. 

A compiler-generated  THUS  list  has  been  added  to  allow 
the  compiler  to  supply  the  transitive  completion  of 
imports  lists  written  by  the  programmer.  Identifiers 
imported  via  THUS  lists  may  not  be  directly  used  by  the 
programmer.  (JAN  1978) . THUS  list  generation  is 
DEFERRED. 

Parameterized  module  types  are  DEFERRED. 

Assignment  and  comparison  of  module  variables  are 
DEFERRED.  Module  variables  as  parameters  to  routines 
are  DEFERRED.  Collections  and  arrays  of  modules  are 
DEFERRED. 

Enforcement  of  type  opaqueness  MAY  BE  DEFERRED. 

The  FINALLY  clause  for  modules  MAY  BE  DEFERRED. 
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The  use  of  the  standard  component  ItsType  on  module 
variables  is  DEFERRED. 


Execution  of  the  invariant  assertion  for  modules  MAY 
BE  DEFERRED. 

The  abstraction  function  declaration  in  a module 
definition  is  DEFERRED. 

Parentheses  are  required  around  an  expression  following 
the  keyword  INVARIANT. 

Enforcement  of  EUCLID  prohibitions  on  the  use  of 
imported  variables  in  the  declaration  part  of  modules 
is  DEFERRED. 

6.2.6  Pointer  and  Collection  types 

Use  of  zones  other  than  the  standard  System  Zone  MAY  BE 
DEFERRED. 

Collections  with  non-manifest  object  types  and  uses  of 
UNKNOWN  to  define  the  object  type  of  a collection  MAY 
BE  DEFERRED. 

Reference  counted  collections  and  CHECKABLE  collections 
(JAN  1978)  will  be  DEFERRED. 

6.3  Parameterized  types 

The  type  of  formal  parameters  to  a parameterized  type 
are  restricted  to  being  simple  manifest  types  (JAN  1978) . 

Non-manifest  actual  parameters  to  types  MAY  BE  DEFERRED. 
Any  use  of  a type  formal  parameter  other  than  as  a tag 
of  a variant  record  case  MAY  BE  DEFERRED. 

The  use  of  FORWARD  in  type  definitions  MAY  BE  DEFERRED. 

6.4  Type  compatability 

The  type  sameness  rule  has  been  substantially  modified 
(JAN  1978) . 

6.5  Explicit  type  conversions 

The  type  converter  " <<="  has  been  deleted.  A functional 
notation  for  type  conversion  has  been  added.  (JAN  1978) . 

7.  Constants  and  variables 

Structured  constants  must  be  manifest  (JAN  1978)  . 
Structured  records  and  module  constants  MAY  BE  DEFERRED. 
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7.4  Binding 

Enforcement  of  the  non-overlap  rule  for  binding  MAY  BE 
DEFERRED. 

The  bind  constant  MAY  BE  DEFERRED. 

9.1.4  Assert  statements 

Parentheses  are  required  around  an  expression  following 
the  keyword  ASSERT. 

9.2. 3.2  For  statement 

Set  and  module  generators  are  DEFERRED. 

10.  Procedures 

Code  blocks  can  contain  only  Unix  assembler  statements. 

The  code  in  these  blocks  can  refer  to  routine 
parameters  but  not  to  imported  variables. 

Routine  formal  parameter  definitions  that  involve  other 
routine  parameters  will  be  DEFERRED.  PARAMETER  is 
supported. 

INLINE  procedures  are  DEFERRED.  Procedures  declared 
using  INLINE  will  be  temporarily  implemented  out  of 
line. 

The  use  of  FORWARD  in  routine  definitions  MAY  BE  DEFERRED. 

Parentheses  are  required  around  an  expression  following 
the  keywords  PRE  and  POST. 

The  Toronto  implementation  allows  the  keyword  EXTERNAL 
to  be  used  in  place  of  the  keyword  FORWARD  to  permit 
linking  to  separately  compiled  C and  Assembler  routines. 

11.  Function  declarations 

The  resultName  in  the  function  header  is  required  rather 
than  optional  (JAN  1978) . 

Functions  returning  non-scalar  values  with  manifest 
types  MAY  BE  DEFERRED. 

Functions  returning  scalar  values  with  non-manifest 
types  MAY  BE  DEFERRED. 

Functions  returning  non-scalar  values  with  non-manifest 
types  are  DEFERRED. 

Parentheses  are  required  around  the  expression  following 
the  keyword  RETURN. 


17 


I 

I 


INLINE  functions  are  DEFERRED.  Functions  declared 
using  INLINE  will  be  implemented  out  of  line. 


Parentheses  are  required  around  an  expression  following 
the  keywords  PRE  and  POST. 

The  Toronto  implementation  allows  the  keyword  EXTERNAL 
to  be  used  in  place  of  the  keyword  FORWARD  to  permit 
linking  to  separately  compiled  C and  Assembler  routines. 


I 

4 


l 

\ 


18 


APPENDIX  D 


Revisions  to  Middle  EUCLID 


Summary  of  the  23  June  1978  telephone  conference  between  the 
EUCLID  Implementation  Team  (R.C.  Holt,  D.B.  Wortman,  and 
D.A.  Bonyun)  and  the  KSOS  implementors  (T.  Berson,  K.  Biba, 
M.  Pliner,  R.  Feiertag) . 


The  language  points  raised  in  Berson' s position  paper  were  dis- 
cussed and  the  following  agreement  was  reached. 

1.  The  implementation  will  try  to  implement  functions  that 
return  values  with  non-scalar  manifest  types  as  soon  as 
possible.  Functions  that  return  non-scalar  non-manifest 
types  will  remain  deferred. 

2.  The  implementation  will  include  (at  least)  "simple" 
parameterized  module  types. 

3.  Forward  type  declarations  will  be  implemented. 

4.  "Simple"  binds  (e.g.  binds  to  array  elements  or  to 
records)  will  be  implemented. 

5.  Set  generators  are  easy  to  do  but  KSOS  doesn't  need  them 
very  much.  Module  generators  are  a lot  harder  and  KSOS 
needs  them  to  encapsulate  its  data  structure  handling. 

The  implementation  team  feels  that  there  may  be  serious 
implementation  problems  with  module  generators.  They  are 
unwilling  to  proceed  with  a module  generator  implementation 
until  these  problems  have  been  investigated  and  the 
interaction  with  other  language  features  has  been  determined. 
Given  the  KSOS  project's  requirement  for  module  generators 
the  implementation  team  will  try  to  implement  them  as  soon 

as  possible. 

6.  Structured  array  constants  (i.e.  for  initialization  tables) 
will  be  implemented  as  soon  as  possible.  The  EUCLID 
translator  also  needs  this  feature.  Structured  record 
constants  can  be  deferred  for  the  time  being. 

7.  Non-standard  zones  can  be  deferred  for  the  time  being  as 
the  initial  implementation  will  allow  users  to  provide 
their  own  runtime  storage  management  routines  for  use  with 
the  standard  zone. 
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8.  Forward  declaration  of  routines  will  be  implemented. 

9.  EUCLID  compiler  will  provide  Pascal- like  type  checking 
and  error  messages  immediately.  Checking  of  imports  and 
exports  lists  and  generation  of  legality  assertions  in 
EUCLID  source  will  be  deferred. 

10.  Manifest  expressions  will  be  allowed  for  labels  in  Pascal- 
like case  statements.  Case  labels  in  variant  record 
definitions  and  discriminating  case  statements  will  be 
restricted  to  (named)  literal  constants. 


Points  11-20  in  Berson's  original  message  are  not  of  immediate 
concern  to  the  KSOS  project.  However,  eventual  provision  of 
many  of  the  features  they  address  is  necessary  for  KSOS'  long 
range  goals  of  performance  and  verifiability.  (See  E,  below). 


OTHER  POINTS 

A.  It  was  agreed  that  instead  of  delivering  a Middle  EUCLID 
translator  at  the  end  of  July  1978  it  would  be  more 
beneficial  to  both  the  Implementation  project  and  the 
KSOS  project  to  deliver  a translator  with  more  features 
(especially  those  noted  above)  as  soon  as  possible,  no 
later  than  mid  Oct  1978. 

B.  The  implementation  team  will  keep  the  KSOS  project  informed 
of  its  progress. 

C.  The  implementation  team  will  arrange  for  the  KSOS  project 
to  have  access  to  preliminary  versions  of  the  EUCLID 
translator  whenever  a reasonably  stable  version  of  the 
translator  exists.  This  may  involve  shipping  a tape 
containing  a binary  image  of  the  compiler  to  KSOS  or 
arranging  for  KSOS  to  have  access  to  the  PDP-11/45  at 
Toronto. 

D.  After  the  telephone  conference  M.  Pliner  and  D.  Bonyun 
arranged  that  Bonyun  and  David  Crowe  from  the  implementation 
team  would  spend  two  days  at  FACC  in  early  August  dis- 
cussing programming  in  EUCLID  with  the  KSOS  project. 

E.  KSOS  felt  that  the  October  version  of  the  EUCLID  translator 
would  provide  a reasonable  initial  tool  for  KSOS 
development.  They  felt  that  there  was  not  a great  need 
for  a full  EUCLID  language  .mplementation  although  some  of 
the  deferred  compiler  features  will  eventually  be  essential. 
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F.  The  telephone  conference  resulted  in  a much  better 
understanding  between  the  two  parties.  The  implementation 
team  has  a better  idea  of  the  KSOS  priorities  and 
schedule.  The  implementation  team  understands  the  KSOS 
projects  concern  that  the  EUCLID  translator  be  on  time  and 
correct.  The  KSOS  project  is  aware  of  the  implementation 
teams  concern  to  produce  a stable,  useful  tool. 

G.  After  the  telephone  conference  the  implementation  team  made 
the  following  assessment  of  the  work  to  be  done  after  mid- 
October  and  the  order  in  which  it  could  be  done. 

1.  Enhancement/maintenance  of  the  mid-October 
translator  as  determined  by  the  needs  of  the  KSOS 
project. 

2.  Implementation  of  the  translator  phase  that  checks 
imports  and  exports  lists  and  enforces  EUCLID'S 
access  rules. 

3.  Implementation  of  non-standard  zones. 

4.  Implementation  of  INLINE  procedures  and  functions. 

5.  Implementation  of  structured  record  constants. 

6.  Generation  of  legality  assertions  in  EUCLID 
source. 

7.  Implementation  of  functions  returning  non-scalar, 
non-manifest  values. 

8.  Implementation  of  other  language  features 
mentioned  in  Berson's  points  11-20. 
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literals,  expressions 

78-3,  Discussion  topics  for  6-7 
Jan  Meeting 

78-4,  More  Discussion  Topics 
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Re:  78-8,  Re  6-7  Jan  Meeting 

Minutes  and  Mss  Code 

78-9,  Re  Syntax  Revisions 

Re:  78-9,  Re  Syntax  Revisions 

Re:  78-9,  Re  Syntax  Revisions 

Re:  78-9,  Re  Syntax  Revisions 

78-10  Re  Draft  of  Jan  meeting 
minutes 

78-11,  Reply  to  JM  Re  Syntax 
Change  #19 

Re:  Re  Type  Sameness  Rule 

Re:  Availability  of  Revised  EUCLID 
Report 

Re:  Availability  of  Revised  EUCLID 

Report 
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78-12,  EUCLID  Problem  with  WITH 
and  Variant  Record  Fields 

Re:  78-12,  EUCLID  Problem  with 

WITH  and  Variant  Record  Fields 

78-13,  EUCLID  Problem  with 
exports  and  routines. 

Re:  78-13,  EUCLID  Problem  with 

exports  and  routines . 

78-14,  EUCLID  Problem  with  THUS 
lists 

Re:  78-14,  EUCLID  Problem  with 

THUS  lists 

78-15,  EUCLID  Problem  7ith  itsTa 

78-16,  Postscript  on  Type 
Sameness  Rule 

Re:  78-16,  Postscript  on  Type 

Sameness  Rule 

78-17,  Legality  Assertions  for 
Parameterized  Module  Types 

Re:  78-17,  Legality  Assertions 

for  Parameterized  Module  Types 

Minutes  of  the  Jan  6-7  meeting 

Re:  Minutes  of  the  Jan  6-7  meeting 

Revised  EUCLID  Report  Schedule 

Re:  EUCLID  verification 

Revised  EUCLID  Report 

Re : Revised  EUCLID  Report 

EUCLID  Type  Sameness  Rule 

Re:  EUCLID  Type  Sameness  Rule 

Re:  Revised  EUCLID  Report 

78-18,  Type  Sameness  vs.  Storage 
Allocation 

Re:  78-18,  Type  Sameness  vs. 

Storage  Allocation 

Re:  78-18,  Type  Sameness  vs. 
Storage  Allocation 

Re:  78-18,  Type  Sameness  vs. 
Storage  Allocation 

Re:  78-18,  Type  Sameness  vs. 
Storage  Allocation 
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